FIG. 1 illustrates a current networked system 100. Conventionally, to make a secure connection between the client 110 and a server 120, the following operations are performed. A web browser on the client is configured to point to a proxy Internet Protocol (IP) address for Hypertext Transfer Protocol Secured (HTTPS) connections. An initial CONNECT request with full Universal Resource Locator (URL) is sent by the client 110 to a proxy 130 between the client 110 and the server 120. The proxy 130 connects to the HTTPS server 120 using the full URL provided in the client's 110 request. The HTTPS server 120 sends back a certificate. The proxy 130 strips out relevant information from the certificate (e.g., common name, etc.) and creates a new certificate signed by a certification-authority certificate, which the user of the proxy 130, i.e., the client 110, has indicated to trust. Eventually, the newly generated certificate is passed to the client 110 and the client 110 accepts the certificate.
Data is decrypted on one connection, and clear-text (i.e., decrypted data) is inspected. Then the data is re-encrypted when sent on another connection. As a result, two TCP/SSL connections 115 and 125 are established, namely, a first connection 125 between the proxy 130 and the server 120, and a second connection 115 between the client 110 and the proxy 130, where each connection supports full Transmission Control Protocol (TCP) flow-control logic. Packet loss re-transmissions are handled individually for each connection and all retransmission scheduling is done on the proxy 130.
One disadvantage of the above scheme is that the client's 110 browser has to be configured with the proxy's IP address. The above scheme is not so scalable due to full TCP based flow control implemented on the inspecting device and due to the fact that sockets do not scale well for large number of connections. Furthermore, it is difficult to configure for non-HTTP protocols.